home *** CD-ROM | disk | FTP | other *** search
/ Freaks Macintosh Archive / Freaks Macintosh Archive.bin / Freaks Macintosh Archives / Textfiles / zines / Phrack / Phrack Issue 53.sit / 53 / P53-06 < prev    next >
Text File  |  1998-07-08  |  15KB  |  299 lines
  1. ---[  Phrack Magazine   Volume 8, Issue 53 July 8, 1998, article 06 of 15
  2.  
  3.  
  4. -------------------------[  T/TCP vulnerabilities
  5.  
  6.  
  7. --------[  route|daemon9 <route@infonexus.com>
  8.  
  9.  
  10. ----[  Introduction and Impetus
  11.  
  12.     T/TCP is TCP for Transactions.  It is a backward compatible extension for
  13. TCP to facilitate faster and more efficient client/server transactions.  T/TCP
  14. is not in wide deployment but it is in use (see appendix A) and it is supported
  15. by a handful of OS kernels including: FreeBSD, BSDi, Linux, and SunOS.  This
  16. article will document the T/TCP protocol in light detail, and then cover some
  17. weaknesses and vulnerabilities.
  18.  
  19.  
  20. ----[  Background and primer
  21.  
  22.     TCP is a protocol designed for reliability at the expense of expediency
  23. (readers unfamiliar with the TCP protocol are directed to the ancient-but-
  24. still-relevant: http://www.infonexus.com/~daemon9/Misc/TCPIP-primer.txt).
  25. Whenever an application is deemed to require reliability, it is usually built
  26. on top of TCP.  This lack of speed is considered a necessary evil.  Short lived
  27. client/server interactions desiring more speed (short in terms of time vs.
  28. amount of data flow) are typically built on top of UDP to preserve quick
  29. response times.  One exception to this rule, of course, is http.  The
  30. architects of http decided to use the reliable TCP transport for ephemeral
  31. connections (indeed a poorly designed protocol).
  32.  
  33.     T/TCP is a small set of extensions to make a faster, more efficient TCP.
  34. It is designed to be a completely backward compatible set of extensions to
  35. speed up TCP connections.  T/TCP achieves its speed increase from two major
  36. enhancements over TCP: TAO and TIME_WAIT state truncation.  TAO is TCP
  37. Accelerated Open, which introduces new extended options to bypass the 3-way
  38. handshake entirely.  Using TAO, a given T/TCP connection can approximate a
  39. UDP connection in terms of speed, while still maintaining the reliability of a
  40. TCP connection.  In most single data packet exchanges (such is the case with
  41. transactional-oriented connections like http) the packet count is reduced by a
  42. third.
  43.  
  44.     The second speed up is TIME_WAIT state truncation.  TIME_WAIT state
  45. truncation allows a T/TCP client to shorten the TIME_WAIT state by up to a
  46. factor of 20.  This can allow a client to make more efficient use of network
  47. socket primitives and system memory.
  48.  
  49.  
  50. ----[  T/TCP TAO
  51.  
  52.     TCP accelerated open is how T/TCP bypasses the 3-way handshake.  Before we
  53. discuss TAO, we need to understand why TCP employs a 3-way handshake.
  54. According to RFC 793, the principal reason for the exchange is the prevention
  55. of old duplicate connection initiations wandering into current connections and
  56. causing confusion.  With this in mind, in order to obviate the need for the
  57. 3-way handshake, there needs to be a mechanism for the receiver of a SYN to
  58. guarantee that that SYN is in fact new.  This is accomplished with a new
  59. extended TCP header option, the connection count (CC).
  60.  
  61.     The CC (referred as tcp_ccgen when on a host) is a simple monotonic
  62. variable that a T/TCP host keeps and increments for every TCP connection
  63. created on that host.  Anytime a client host supporting T/TCP wishes to make a
  64. T/TCP connection to a server, it includes (in it's TAO packet) a CC (or CCnew)
  65. header option.  If the server supports T/TCP, it will cache that client's
  66. included CC value and respond with a CCecho option (CC values are cached by
  67. T/TCP hosts on a per host basis).  If the TAO test succeeds, the 3-way
  68. handshake is bypassed, otherwise the hosts fall back to the older process.
  69.  
  70.     The first time a client host supporting T/TCP and a server host supporting
  71. T/TCP make a connection no CC state exists for that client on that server.
  72. Because of this fact, the 3-way handshake must be done.  However, also at that
  73. time, the per host CC cache for that client host is initialized, and all
  74. subsequent connections can use TAO.  The TAO test on the server simply checks
  75. to make sure the client's CC is greater then the last received CC from that
  76. client.  Consider figure 1 below:
  77.  
  78.       Client                               Server
  79. T   -----------------------------------------------------------------------
  80. i   0       --TAO+data--(CC = 2)-->        ClientCC = 1
  81. m   1                                      2 > 1; TAO test succeeds
  82. e   2                                      accept data ---> (to application)
  83.  
  84.                             [ fig 1 ]
  85.  
  86.     Initially (0) the client sends a TAO encapsulated SYN to the server, with
  87. a CC of 2.  Since the CC value on the server for this client is 1 (indicating
  88. they have had previous T/TCP-based communication) the TAO test succeeds (1).
  89. Since the TAO test was successful, the server can pass the data to application
  90. layer immediately (2).  If the client's CC had not been greater than the
  91. server's cached value, the TAO test would have failed and forced the 3-way
  92. handshake.
  93.  
  94.  
  95. ----[  T/TCP TIME_WAIT truncation
  96.  
  97.     Before we can see why it is ok to shorten the TIME_WAIT state, we need to
  98. cover exactly what it is and why it exists.
  99.  
  100.     Normally, when a client performs an active close on a TCP connection, it
  101. must hold onto state information for twice the maximum segment lifetime (2MSL) 
  102. which is usually between 60 - 240 seconds (during this time, the socket pair
  103. that describes the connection cannot be reused).  It is thought that any
  104. packet from this connection would be expired (due to IP TTL constraints) from
  105. the network.  TCP must be consistent with its behavior across all contingencies
  106. and the TIME_WAIT state guarantees this consistency during the last phase of
  107. connection closedown.  It keeps old network segments from wandering into a
  108. connection and causing problems and it helps implement the 4-way closedown
  109. procedure.  For example, if a wandering packet happens to be a retransmission
  110. of the servers FIN (presumably due to the clients ACK being lost), the client
  111. must be sure to retransmit the final ACK, rather then a RST (which it would do
  112. if it had torn down all the state). 
  113.  
  114.     T/TCP allows for the truncation of the TIME_WAIT state.  If a T/TCP
  115. connection only lasts for MSL seconds or less (which is usually the case with
  116. transactional-oriented connections) the TIME_WAIT state is truncated to as
  117. little as 12 seconds (8 times the retranmission timeout - RTO).  This is
  118. allowable from a protocol standpoint because of two things: CC number
  119. protection against old duplicates and the fact that the 4-way closedown
  120. procedure packet loss scenario (see above) can be handled by waiting for the
  121. RTO (multiplied by a constant) as opposed to waiting for a whole 2MSL.
  122.  
  123.     As long as the connection didn't last any longer then MSL, the CC number
  124. in the next connection will prevent old packets with an older CC number from
  125. being accepted.  This will protect connections from old wandering packets
  126. (if the connection did last longer, it is possible for the CC values to wrap
  127. and potentially be erroneously delivered to a new incarnation of a connection).
  128.  
  129.  
  130. ----[  Dominance of TAO
  131.  
  132.     It is easy for an attacker to ensure the success or failure of the TAO
  133. test.  There are two methods.  The first relies on the second oldest hacking
  134. tool in the book.  The second is more of a brutish technique, but is just as
  135. effective.
  136.  
  137.  
  138. --[  Packet sniffing
  139.  
  140.     If we are on the local network with one of the hosts, we can snoop the
  141. current CC value in use for a particular connection.  Since the tcp_ccgen is
  142. incremented monotonically we can precisely spoof the next expected value by
  143. incrementing the snooped number.  Not only will this ensure the success of our
  144. TAO test, but it will ensure the failure of the next TAO test for the client
  145. we are spoofing.
  146.  
  147.  
  148. --[  The numbers game
  149.  
  150.     The other method of TAO dominance is a bit rougher, but works almost as
  151. well.  The CC is an unsigned 32-bit number (ranging in value from 0 -
  152. 4,294,967,295).  Under all observed implementations, the tcp_ccgen is
  153. initialized to 1.  If an attacker needs to ensure the success of a TAO
  154. connection, but is not in a position where s/he can sniff on a local network,
  155. they should simply choose a large value for the spoofed CC.  The chances that
  156. one given T/TCP host will burn through even half the tcp_ccgen space with
  157. another given host is highly unlikely.  Simple statistics tells us that the
  158. larger the chosen tcp_ccgen is, the greater the odds that the TAO test will
  159. succeed.  When in doubt, aim high. 
  160.  
  161.  
  162. ----[  T/TCP and SYN flooding
  163.  
  164.     TCP SYN flooding hasn't changed much under TCP for Transactions.  The
  165. actual attack is the same; a series of TCP SYNs spoofed from unreachable IP
  166. addresses.  However, there are 2 major considerations to keep in mind when
  167. the target host supports T/TCP:
  168.  
  169.     1) SYN cookie invalidation:  A host supporting T/TCP cannot, at the same
  170.        time, implement SYN cookies.  TCP SYN cookies are a SYN flood defense
  171.        technique that works by sending a secure cookie as the sequence number
  172.        in the second packet of the 3-way handshake, then discarding all state 
  173.        for that connection.  Any TCP options sent would be lost.  If the final
  174.        ACK comes in, only then will the host create the kernel socket data
  175.        structures.  TAO obviously cannot be used with SYN cookies.
  176.  
  177.     2) Failed TAO processing result in queued data: If the TAO test fails, any
  178.        data included with that packet will be queued pending the completion of
  179.        the connection processing (the 3-way handshake).  During a SYN flood,
  180.        this can make the attack more severe as memory buffers fill up holding
  181.        this data.  In this case, the attacker would want to ensure the failure
  182.        of the TAO test for each spoofed packet.
  183.  
  184.     In a previous Phrack Magazine article, the author erroneously reported that
  185. T/TCP would help to alleviate SYN flood vulnerability.  This obviously
  186. incorrect statement was made before copious T/TCP research was done and is
  187. hereby rescinded.  My bad.
  188.  
  189.  
  190. ----[  T/TCP and trust relationships
  191.  
  192.     An old attack with a new twist.  The attack paradigm is still the same,
  193. (readers unfamiliar with trust relationship exploitation are directed to
  194. P48-14) this time, however, it is easier to wage.  Under T/TCP, there is no
  195. need to attempt to predict TCP sequence numbers.  Previously, this attack
  196. required the attacker to predict the return sequence number in order to
  197. complete the connection establishment processing and move the connection into
  198. the established state.  With T/TCP, a packet's data will be accepted by the
  199. application as soon as the TAO test succeeds.  All the attacker needs to do is
  200. ensure that the TAO test will succeed.  Consider the figure below.
  201.  
  202.      Attacker                     Server                          Trusted
  203.     -----------------------------------------------------------------------
  204.     0         -spoofed-TAO->
  205.     1                          TAO test succeeds
  206. T   2                          data to application
  207. i   3                                            ---TAO-response->
  208. m   4                                                        no open socket
  209. e   5                                            <------RST-------
  210.     6                          tears down connection
  211.  
  212.                             [ fig 2 ] 
  213.  
  214.     The attacker first sends a spoofed connection request TAO packet to the
  215. server.  The data portion of this packet presumably contains the tried and true
  216. non-interactive backdooring command `echo + + > .rhosts`.  At (1) the TAO test
  217. succeeds and the data is accepted (2) and passed to application (where it is 
  218. processed).  The server then sends its T/TCP response to the trusted host (3).
  219. The trusted host, of course, has no open socket (4) for this connection, and
  220. responds with the expected RST segment (5).  This RST will teardown the
  221. attacker's spoofed connection (6) on the server.  If everything went according
  222. to plan, and the process executing the command in question didn't take too long
  223. to run, the attacker may now log directly into the server.
  224.  
  225.     To deal with (5) the attacker can, of course, wage some sort of denial of
  226. service attack on the trusted host to keep it from responding to the
  227. unwarranted connection.
  228.  
  229.  
  230. ----[  T/TCP and duplicate message delivery
  231.  
  232.     Ignoring all the other weaknesses of the protocol, there is one major flaw
  233. that causes the T/TCP to degrade and behave decidedly NONTCP-like, therefore
  234. breaking the protocol entirely.  The problem is within the TAO mechanism.
  235. Certain conditions can cause T/TCP to deliver duplicate data to the
  236. application layer.  Consider the timeline in figure 3 below:
  237.  
  238.       Client                               Server
  239.     -----------------------------------------------------------------------
  240.     0                    --TAO-(data)--->
  241.     1                                      TAO test succeeds
  242. T   2                                      accept data ---> (to application)
  243. i   3                                      *crash*     (reboot)
  244. m   4  timeout (resends) --TAO-(data)--->
  245. e   5                                      TAO test fails (data is queued)
  246.     6  established       <-SYN-ACK(SYN)--  fallback to 3WHS
  247.     7                    --ACK(SYN)----->  established (data --> application)
  248.  
  249.                             [ fig 3 ]
  250.  
  251.     At time 0 the client sends its TAO encapsulated data to the server (for
  252. this example, consider that both hosts have had recent communication, and the
  253. server has defined CC values for the client).  The TAO test succeeds (1) and
  254. the server passes the data to the application layer for processing (2).
  255. Before the server can send its response however (presumably an ACK) it crashes
  256. (3).  The client receives no acknowledgement from the server, so it times out
  257. and resends its packet (4).  After the server reboots it receives this
  258. retransmission, this time, however, the TAO test fails and the server queues
  259. the data (5).  The TAO test failed and forced a 3-way handshake (6) because the
  260. servers CC cache was invalidated when it rebooted.  After completing the 3-way
  261. handshake and establishing a connection, the server then passes the queued data
  262. to the application layer, for a second time.  The server cannot tell that it
  263. has already accepted this data because it maintains no state after a reboot.
  264. This violates the basic premise of T/TCP that it must remain completely
  265. backward compatible with TCP.
  266.  
  267.  
  268. ----[  In closing
  269.  
  270.     T/TCP is a good idea that just wasn't implemented properly.  TCP was
  271. not designed to support a connectionless-like paradigm while still
  272. maintaining reliability and security (TCP wasn't even designed with security
  273. in mind at all).  T/TCP brings out too many problems and discrete bugs in TCP
  274. to be anything more then a novelty. 
  275.  
  276.  
  277. ----[  Appendix A: Internet hosts supporting RFC 1644
  278.  
  279.     This information is ganked from Richard Steven's T/TCP homepage 
  280. (http://www.kohala.com/~rstevens/ttcp.html).  It is not verfied to be correct.
  281.     - www.ansp.br
  282.     - www.elite.net
  283.     - www.iqm.unicamp.br
  284.     - www.neosoft.com
  285.     - www.sbq.org.br
  286.     - www.uidaho.edu
  287.     - www.yahoo.com
  288.  
  289.  
  290. ----[  Appendix B: Bibliography
  291.  
  292.     1) Braden, R. T. 1994 "T/TCP - TCP Extensions for Transactions...", 38 p
  293.     2) Braden, R. T. 1992 "Extending TCP for Transactions - Concepts...", 38 p
  294.     3) Stevens, W. Richard. 1996 "TCP Illustrated volume III", 328 p
  295.     4) Smith, Mark. 1996, "Formal verification of Communication...", 15 p
  296.  
  297.  
  298. ----[  EOF
  299.